1. Field of the Invention
The present invention relates to computer systems and systems-on-a-chip (SOCs). More specifically, the present invention relates to IDE controllers used in computers and SOCs to communicate with external devices and systems.
2. Description of the Related Art
The ATA/IDE interface has evolved over the past several years to support faster timings for greater data bandwidth on the interface. Starting with the initial ATA/IDE specification, entitled “0791 M AT Attachment Interface for Disk Drives” (ATA-1), which was developed under the authority of the American National Standards Institute (ANSI) by Technical Committee 13 of the International Committee on Information Technology Standards (INCITS), there have been several revisions to support more data throughput across the interface. The introduction of the Ultra DMA 33 protocol allowed ATA/IDE devices to transfer data at rates up to 33 MB per second. The next revision, Ultra DMA 66, allowed data transfer rates that were twice as fast, up to 66 MB per second. Two subsequent revisions, Ultra DMA 100 and more recently Ultra DMA 133 allowed for data to be transmitted at rates of 100 MB per second and 133 MB per second, respectively. The original ATA/IDE specification and all subsequent revisions are available from the American National Standards Institute at 25 West 43rd Street, New York, N.Y. 10036, and are incorporated by reference for all purposes into this specification.
When Ultra DMA 33 was initially introduced, companies designed controllers to support the new ATA/IDE Ultra DMA 33 compliant devices. Much of the design involved handling the signaling interface to meet the proper timing required by the specification. The design was typically implemented using state machines and counters with hard coded values. This hardware would generate the control signals and data strobes to match the timing parameters required by the Ultra DMA 33 specification. These designs also used a system clock frequency of 33 Mhz, which is the native clock frequency for running Ultra DMA 33 transfers. When the Ultra DMA 66 specification came out, companies had to design new controllers to handle the updated timings to the specification. These controllers were implemented again in a similar fashion using state machines and counters with hard coded timing parameter values to meet the timing requirements on the Ultra DMA 66 interface. The controllers used a clock frequency of 66 Mhz, which is the native clock frequency for Ultra DMA 66 transfers.
As the next generation specifications for Ultra DMA 100 and Ultra DMA 133 were defined, new controllers were introduced supporting these latest interfaces, but these either did not fully support the previous Ultra DMA 33 or Ultra DMA 66 interfaces (and Ultra 100 when Ultra DMA 133 was introduced) or did not run at an optimal transfer rate when running at those slower speeds. This was not an issue in many systems, since the controller designs were optimized in terms of gate counts and performance for the highest interface speed, and these designs were typically used in a single project or environment for a specific clock frequency and device speed (e.g. operation at 133 Mhz to work only with Ultra DMA 133 devices).
However, problems with reuse arose when a host controller targeted for one clock frequency and device speed needed to support multiple systems that ran at different clock frequencies and had to support multiple Ultra DMA speeds. Normally, a different controller had to be used for each system to accommodate that system's interfaces and operating frequencies. Ultra DMA 33's natural clock frequency runs at 33 Mhz (30 ns clock period). Similarly, Ultra DMA 66 runs at 66 Mhz (15 ns clock period), Ultra DMA 100 at 100 Mhz (10 ns clock period), and Ultra DMA 133 runs at 133 Mhz (7.5 ns clock period). A controller designed to handle Ultra DMA 133 transfers assumes a system clock speed of 133 Mhz and thus defines its timing parameters in number of clock cycles, where a clock cycle has a 7.5ns period. Internal counters in the design check to make sure that enough clock cycles have elapsed to meet the minimum timing parameter for a transaction, or that a signal has changed before the maximum timing requirement for a specific transaction is reached. A controller optimized for use in a 133 Mhz system cannot be used in a slower system (for example, one designed for Ultra DMA 33 transfers that uses a 33 Mhz input clock having a 30ns clock period), because all of the timing parameters must be recalculated. For example, a transaction or event with a maximum allowed timing of 70ns can be met with a defined timing parameter of 8 clock cycles (60ns total) in a system running at 133 Mhz, but when the system clock is slowed down to 33 Mhz, the 8-clock cycle requirement translates to 240 ns. This exceeds the allowable maximum time allocated for the transaction.
Supporting all of the Ultra DMA modes (Ultra DMA 33, Ultra DMA 66, Ultra DMA 100 and Ultra 133) at their native clock frequencies (33 Mhz, 66 Mhz, 100 Mhz and 133 Mhz, respectively) required four different versions of the host controller, one for each clock frequency. While optimizing a host controller for a specific system enabled designers to save on the number of gates and achieve a more efficient design for the specific application, an obvious disadvantage to this approach is design maintenance. Supporting and maintaining at least four different designs is clearly more difficult that supporting and maintaining one design.
To address this issue, designers created a single hardware description language design base that included configuration directives specifying which speed a specific instantiation of the design would be optimized for. This approach allowed all of the different hard coded parameters to exist within a single design base. For example, a host controller base design described in Verilog would use the “ifdef” construct, coupled with a special identifier, to specify which speed a design being instantiated is optimized for. Similar constructs exist for other HDL languages. This technique can generate hard coded parameters for the four native clock frequencies (33 Mhz, 66 Mhz, 100 Mhz, and 133 Mhz) for each Ultra DMA transfer mode (Ultra DMA 33, Ultra DMA 66, Ultra DMA 100, and Ultra DMA 133, respectively) as well as the other data transfer modes (Taskfile Accesses, PIO Data Transfers and Multiword DMA Transfers). Using this approach, when a host controller is required for a particular transfer speed, special scripts that invoke the configuration directives are used to preserve the proper hard coded parameters for that particular frequency and strip the other parameters out. This generates an optimized design in terms of timing and performance with the proper hard coded parameters from the design base. This approach simplifies maintenance of the design, since only one design base needs to be maintained.
While partially addressing the multiple-design maintenance issue, using a configuration directive script with the generic design base still results in different hardware configurations, and therefore, does not enable the use of a single controller configuration which supports different systems and different clock frequencies. This is a problem in SOCs that have an integrated ATA/IDE host controller, because SOC manufacturers want their chips to be usable across a variety of environments, even though each environment may be running at a different clock frequency. In addition, some systems may not even run their system clock frequencies at the native speeds of 33 Mhz, 66 Mhz, 100 Mhz or 133 Mhz. For example, some environments might have to run at faster speeds (166 Mhz, 200 Mhz) or non-native frequencies (40 Mhz, 80 Mhz, etc) due to system synchronization issues or foundry process limitations. Obviously, a single design having hard coded parameters—even one generated from a generic design base using a configuration directive script—cannot be used across all of these different environments.
An ATA/IDE host controller that provides support for non-native clock frequencies and that is usable across multiple environments running at different clock frequencies is therefore required. The present invention is such a device. The ATA/IDE host controller of the present invention uses special programmable registers that allow default hard-coded timing parameters to be overridden by values programmed to insure compliance with ATA/IDE timing requirements under the current operating parameters of the system environment in which the host controller is operating. This allows the system user to use the present invention's default timing parameters, or to reprogram the timing parameters when the present invention is used in a system environment with a different clock frequency. In addition, the present invention supports on-the-fly timing parameter reprogramming, to enable its use in systems that allow the system clock frequency to change during regular operation. For example, some systems reduce clock frequencies on-the-fly to minimize power consumption or to reduce heat generation. Reprogramming timing parameters on the fly allows the present invention to continue to support the same ATA/IDE transactions at the same data rate, even when the system clock frequency is reduced.